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ABSTRACT 



In an information appliance system 100, a user device 108 
comprises a client platform (200, FIG. 5) that includes a 
service framework (235, FIG. 5) to discover and connect 
with a variety of services, both remote and local, transient 
and persistent, and to disconnect from them when they are 
no longer of interest or become unavailable. The service 
framework 235 provides a standard, consistent, simplified 
way for services to make themselves available and for 
service-using entities to locate and connect with the services 
of interest to them. The service framework 235 comprises 
service event notification registries (254, 256, FIG. 7) in 
which service-requesting entities register templates defining 
the types of services they want to locate and connect with. 
However, the service framework 235, rather than connecting 
with any service that matches a desired service type, can 
further control a remote service lookup operation in accor- 
dance with various transport characteristics in the template, 
such as signal strength, quantity of data to be transferred, 
range, available bandwidth, communications cost, service 
location, time of day, vehicular velocity, and so forth. This 
conserves the platform's memory and bandwidth resources 
by not connecting with services that would not satisfy a 
user's request or that would be unduly transitory. Various 
methods of operating a service framework are also 
described. 

12 Claims, 11 Drawing Sheets 
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METHOD OF PROVIDING A REMOTE SERVICE TO A .50O 
COMMUNICATIONS PLATFORM USING SERVICE ATTRIBUTES 



I 



USE A WIRELESS INTERFACE TO COUPLE THE COMMUNICATIONS 
PLATFORM TO A REMOTE COMMUNICATIONS NODE. THE REMOTE 
COMMUNICATIONS NODE INCLUDES SERVICE OBJECTS. AT LEAST ^502 
ONE SERVICE ATTRIBUTE, AND A REMOTE LOOKUP SERVICE 
BACKEND. THE COMMUNICATIONS PLATFORM HAS A SERVICE 
FRAMEWORK. INCLUDING A REMOTE LOOKUP SERVICE FRONTEND. 

1 

THE REMOTE LOOKUP SERVICE BACKEND COMMUNICATES THE AT 
LEAST ONE SERVICE ATTRIBUTE IN THE REMOTE COMMUNICATIONS ^^^^ 
NODE TO THE REMOTE LOOKUP SERVICE FRONTEND. 



(ASYNCHRONOUSLY) 
SERVICE-REQUESTING ENTITY REQUESTS A REMOTE SERVICE. THE 
SERVICE-REQUESTING ENTITY CONSTRUCTS A SERVICE TEMPLATE 

REPRESENTING THE REMOTE SERVICE. THE SERVICE TEMPLATE \^506 
HAS AT LEAST ONE SERVICE ATTRIBUTE. THE SERVICE ATTRIBUTE 
DESCRIBES A TRANSPORT ATTRIBUTE OF THE REMOTE 
COMMUNICATIONS MODE. OR A PREFERENCE OF THE SERVICE 
REQUESTING-ENTITY REGARDING THE REQUESTED REMOTE SERVICE. 



THE SERVICE-REQUESTING ENTITY ISSUES THE SERVICE L-^ng 
TEMPLATE TO THE SERVICE FRAMEWORK T 




FIG. 11 
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SERVICE FRAMEWORK FOR EVALUATING 
REMOTE SERVICES BASED UPON 
TRANSPORT CHARACTERISTICS 

RELATED INVENTIONS 

This invention is related to the following inventions 
which are assigned to the same assignee as the present 
invention and which were filed on even date herewith: 

Sen No. 09/662,439. entitled "Service Framework Sup- 
porting Remote Service Discovery and Connection"; 

Sen No. 09/663,523, entitled "Service Framework with 
Just-In-Time Look-Up"; 

Sen No. 09/663,522, entitled "Service Framework with 
Consolidation of Local and Remote Services"; 

Sen No. 09/663,278, entitled "Service Framework with 
Local Proxy for Representing Remote Services"; and 

Sen No. 09/662,441, entitled "Service Framework With 
Hidden Services". 

HELD OF THE INVENTION 

This invention relates generally to communications sys- 
tems and, in particular, to methods and apparatus for pro- 
viding services to wireless equipment in a wireless commu- 
nications system. 

BACKGROUND OF THE INVENTION 

There is an ever increasing demand for wireless commu- 
nications. Wireless subscribers desire to have access to 
information at any time and at any place. One of the fastest 
growing markets for providing wireless services is known as 
"telematics" and entails delivering a wide spectrum of 
information via wirelesslin k s to vehicle -based subscribers.* 
TUB UlTUrHlillioli can ongirSte*^ V 
as the Int erne^ a nd other pub lic, priva te, and^or gover nment 
com' pinS ^ased networks ;.jvireless_teiecomm 

satellite, land -mobile and the like; terrestrial and satellite 
dif^^i^f^^umSpWdl!i5^^ 
broadband,3teJeyisiQn,^^ geolocation and navigationjyia 



thaTarc of interest to^it.. as well as to disconnect from 



10 



20 



25 



30 



35 



40 



50 



a~globaCpQsition„system (GPS), 'jTHHTlre like; ~^ncierge 
se rvices p_rovidm g roadside assis tan^, c merge nc>Mcalling, 
r e m^te- doo^ ^ unloving, "^cT ^VHe nt re^ppH'infi r^ uay e^l 
conditions, v ehicle secT| ritv, stolen vehicle recovery, remote 
vchiclejdiagrfostics, and the like; ao veiTising servi ces id _cn 
"*io^ion? 



tifylhg names and iocatio'ris*'or'busiriesses such as gas 
stations, restaurants, hotels, stores, and oflBces, and the like; 
totlrist'ser^ces'sifch'^as^p^irtsWiifl^T^^ 
(access, and the like; and many other sources that can provide 
information of any type. Many of the above services are not 
universally available, butj[aUier^.Jhey^ejtjr^^ 
time'anS^geoposition domains. \ 

In forrnation can be c ommunicated to tel emat ics devices 55 
o verrcJa^tiv elY long wireiess links, sdbrr^a^ 
terrestnal^node, or from relatively-sho rt wireless o r wired 
Iml^^icluas from i rKveh icle'cqu ipiBSijjjrJgQm^ '^^ 
devices like foAs, p ortable co mputers, cellular phoncg, arid 



65 



he services provided by telematics systems are not 
restricted to vehicle -based subscribers, and they can also be 
provided to subscribers at home, at work, or. else where. Wit h 
so rm^biTiTyrrttreygq^ ripment located in the_s ubscriber*s 
vehicle, or the equipment carried by or otherwise serving a 
subscriber, needs a way to connect with the plethora of 
services that are potentially available to it. The equipment 



ser\^xsJgal^j§^^Stdonger«of interest to it. 

It IS known in the prior art to utilize certain commercially 
available software to locate services. However, systems 
utilizing such software are fixed, not mobile. Mobile sys- 
tems require connection software that is specifically 
designed to fulfill requirements that distinguish mobile 
systems from fixed systems. For example, mobile systems 
often have limited battery power, limited bandwidth, limited 
memory, and only stay in any given place for a limited time. 

Mobile systems also may have rigorous security require- 
ments in order to protect the identify and location of mobile 
subscribers, as well as to insure that the mobile equipment, 
including software, is not involuntarily ahered or corrupted, 
for example, by downloading uncertified software that could 
replace, infect, or otherwise have an adverse impact upon 
the software residing in the system. Known systems that 
dynamically provide access to services typically download 
software code to the client platform and execute the code on 
the client platform. Not only does this introduce potentially 
dangerous security issues, but the downloaded code can 
overwhelm the mobile system's limited memory capability. 

It is known in the art for potentially all services that could 
be requested by an application on a client platform to 
register as available. For example, in the Jini™ connection 
technology commercially available from Sun Microsystems, 
Palo Alto, Calif,, services register themselves with all 
lookup servers belonging to the same group, irrespective of 
demand for the services. However, this can be a disadvan- 
tage in a mobile platform, because the platform's commu- 
nications trafiSc could be excessive, and further the plat- 
form's memory resources could be quickly depleted. 
Moreover, in a mobile environment, the client platform may 
only be within range of or be able to communicate with a 
remote service provider for a brief time or with an accept- 
able signal-to-noise ratio. Further, a user of a mobile system 
may desire only a specific type of service, and it would be 
inefiBcient to lookup and supply the user with services that 
did not satisfy the user's specific request. 

Accordingly, there is a significant need for methods and 
apparatus that are more conserving of resources in the client 
platform, particularly for mobile platforms. 

There is also a significant need for methods and apparatus 
that do not automatically populate a client platform's service 
registry with entries representing all of the remote services 
requested by applications, but that look up and connect only 
those services that satisfy a user's request and that have a 
reasonable chance of being found and connected to, particu- 
larly in view of changing conditions pertaining to a mobile 
platform. 

There is further a significant need for methods and 
apparatus that control access to remote services based in part 
upon transport characteristics of a mobile platform without 
unnecessarily involving appUcations that reside in the 
mobile platform. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The invention is pointed out with particularity in the 
lippended claims. However, other features of the invention 
will become more apparent and the invention will be best 
understood by referring to the following detailed description 
in conjunction with the accompanying drawings in which: 

FIG. 1 depicts an exemplary information appliance 
system, according to one embodiment of the invention; 

FIG. 2 depicts a user node of an exemplary information 
appliance system; 
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FIG. 3 depicts a local node of an exemplary informationi 
appliance system; 

FIG. 4 depicts a regional node of an exemplary informa- 
tion appliance system; 

FIG. 5 illustrates major functional software blocks of a 
client platform, according to one embodiment of the inven- 
tion; 

FIG. 6 illustrates major functional software blocks of a 
server platform, according to one embodiment of the inven- 
tion; 

RG. 7 illustrates a simplified block diagram showing 
various components of a service framework, according to 
one embodiment of the invention; 

FIG. 8 illustrates a diagram depicting a local service 
lookup operation, as performed by a service framework, 
according to one embodiment of the invention; 

FIG. 9 illustrates a diagram depicting the initiation of a 
remote service discovery operation, as performed by a 
service framework, according to one embodiment of the 
invention; 

FIG. 10 illustrates a diagram depicting the conclusion of 
a remote service discovery operation, as performed by a 
service framework, according to one embodiment of the 
invention; and 

nGS. 11 and 12 together illustrate a flow diagram of a 
method of providing a remote service to a communications 
platform using service attributes, according to one embodi- 
ment of the invention. 

DETAILED DESCRIPTION OF THE DRAWINGS 

The present invention is a distributed communications 
system with software components running on mobile client 
platforms and on remote server platforms. 

FIG. 1 depicts an exemplary information appliance sys- 
tem 100, according to one embodiment of the invention. 
Shown in FIG. 1 are examples of components of an infor- 
mation appliance system 100, which comprises a plurality of 
servers 102 coupled to a regional node 104, and a plurality 
of local nodes 106 coupled to regional node 104. There can 
be any number of servers 102, regional nodes 104, and local 
nodes 106 within the information appliance system 100. The 
regional node 104 can be coupled to a network, such as the 
Internet 114, and to any number of concierge services 112. 

Servers 102, while illustrated as coupled to regional node 
104, could be implemented at any hierarchical level(s) 
within information appliance system 100. For example, 
servers 102 could also be implemented within one or more 
local nodes 106, concierge service 112, and Internet 114. 

Without limitation, local node 106 can be a kiosk, cell 
site, local area network (LAN), telephone company, cable 
comp any, satellite, or anp^iher "information service, 
structure^'or eniity^'t hat ca n tra nsmit , receive, and/or com- 



(P (^S) teleph on 
such as aj 




15 



35 



40 



L aggr^.jUiand;held^CO_mp_uting^deyic^ 

^ _ STassistant (PDA) or Web a ppliance, 

or any other type of communications "iSci/or computing 
device . WithouyimitJ^tion,^ae.5rjiiorc 
, b^ contained within ^a n d opti^ ja ^^y^ fo^ I 
• vetucie» ^ suc b als a c^ ^ ^ tfaih",' _aircraft, or [ 

oa tl o^^yJypLcH^^ s jj ^^ office,^ school, | 

nunercial establishment''analBe'lilceTl^^ 
aluser node 108 can also be implemented in a device that can 
bp carried by the user of the information appliance system 

In one embodiment, a user node 108 comprises an 
in -vehicle information appliance comprising various human 
interface (H/I) elements such as a displa v_^j3L a multi- i 



position controller 113, one or more control knobs 115 and J 
116, one or more in di cators 117 such as bu lbs or ligh t f 
en^ittingjil^des (CE^^ controTblittons ll8,[ 

oneTTmorT^E^ttiST^'SJZrTmifc'fflpfiSn^^ I 
H/I elements required by the particular applications to be ^ 
utilized in conj unction with the information appl ianrr, — 
20 A user noaes li>8 can also transmit and/or receive data tol 
/ and from devices and services other than local node 106. For \ 
/ example, user nodes 108 can transmit and receive data to) 

(^a ndJ&Com a satelli te 110. ■ — 

' J'he information appliance system 100 including the user 
25 nodes 108 is capable of utilizing audio data in any number 
of encoding methods from any number of sources that 
include, but are not limited to, AD PCM (adaptive differen- 
tial pulse-code modulation); CD-DA (compact disc — digital 
audio) digital audio specification; and ITU (International 
30 Telecommunications Union) Standards G.711,G.722,G.723 
& G.728. 

The information appliance system 100 including the user 
nodes 108 is capable of utilizing video data in any number 
of encoding methods from any number of sources that 
include, but are not limited to, ITU Standards H.261 & 
H.263; Motion JPEG (Joint Photographic Experts Group); 
and MPEG-1, MPEG-2 and MPEG-4 (Motion Picture 
Experts Group) standards. 

Additionally, the information appliance system 100 is 
capable of utilizing audio and video data in any number of 
formats and using any type of transport technology that 
include, but are not limited to, USB (Universal Serial Bus); 
IEEE (Institute of Electrical and Electronics Engineers) 
Standards 1394 — 1995; and IEEE 802.11; and using proto- 
cols such as HTTP (hypertext transfer protocol); T CP/IP 
45 (transmission contr ol prntnail/Tnt emef prnlncnl); and UDP/ 
IP (user datagram protocol/Internet protocol). 

EIG. 2 depicts a user no de 108 of an exemplary_informa- 
tion'appHance^S)^(em^"flJ^^^ node 
108 can without limitation be located within or be an*inte^al 



co mmunic ations. 

Local node 106 is coupled to any number of user nodes 
108 via wireline or wireless interface means . In the embodi- 
ment depicted in FIG. 1, user nodes 108 can transmit and 
receive information using wireless communications means. 
User nodes 108 without limitation can include a wireless 
unit such as a cellular or Personal Communication Seryicg 



a stTtioffary location*"©^ likefjKs shown in 

FIG. 2, the user^node 108 comprises a processor 120 with 

associated user^node memory 128. User node memory 128 

municate information. An info rmati on service can be any 55 coinprises user node cont'f^ User' node 

desired service including, out not limited to, Eaernory 128 can include^'but is dot liniiited t67 random 
telec ommuni cfi tinng, HrnnHhnn rL communications, access memory (RAM), read only memory (ROM), flash 
pniyrtain piftnf , tpJfty iginnj radio, record ed t nusic, movies, memory, and other memory such as a hard disk, floppy disk, 
computer-based games, Inte rnet, a nd other types of public, and/or other appropriate type of memory. User node 108 can 
priv^^__ger§onal7 commercial, government, and military' 60 initiate and perform communications with other nodes 

shown in FIG. 1 in accordance with suitable computer 
programs, such as user node control algorithms 126, stored 
in user node memory 128. 

User node 108 also comprises a user interface device 130 
65 that can include without limitation a tactile interface 134, 
microphone 133, speakers 132, any number of displays 131, 
and the like. 




12/03/2003, EAST Version: 1.4.1 



us 6,580,916 Bl 
5 6 

User node 108 also comprises an extra-vehicle interfacel various components and systems can also communicate via 
122, typically implemented as a transmitter/receiver fori ^^g,fe^JJ,jigiSw^M£L?^ wireline, radio frequency (RF), or 
transmitting and receiving communications via a wireless^ ^ op^^^ ^^ aSHBTi fi^rwitOthe r^loc^ 



link 1 44 amon g ; the various nodes depicted in FIG. 1. 
E xtra-vehicle interface 122 alsoifacilitates.communicationS 
am ong other de vic£s^a^wiFeless4iQ k^l59. for exam ple, 
sat ellite 110. and the like. Communications arfi OransmiUed 
a n'd received thi ousb-Qne or-siQre^aolennas.142 of any type, 
wliich can include any one or combination of a fixed, 
steerable, omni-directional, or phased array anienna|^teer^ 
able antenna can include, but is not limited to, an electroni- 
cally steerable antenna, physically steerable antenna, and the 
like. User node 108 can also include positioning devices 124 
of any type, for example, global positioning system (GPS), 



regio^J^odes 104, 

In one embodiment, the variotis components and systems 
in FIG. 3 can communicate with each other via a wireline 
link 135, for example, a power/data/control bus, and the like. 
In another embodiment, some of the various components 
and systems in FIG. 3 cx)uld communicate via a wireless 
Unk. 

FIG. 4 depicts a regional node 104 of an exemplary 
information appliance system 100. As sho\vn in FIG. 4, the 
regional node 104 comprises a processor 123 with associ- 
ated regional node memory 152. Regional node memory 152 



1 V])' 



gyroscope, compass, accelerometer, altimeter, rate sensors, 15 comprises regional node control algorithms 150. Regional 



and other positioning devices 124 that can define the 
position, attitude, and/or motion vector of the user node 108. 

User node 108 can also comprise an intra-vehicle intcr-^ 
face 136, which can include antenna 160. Intra-vehicle 
interface 136 can include multiple types of transceivers (not 
shown) and antennas 160 to im]3lem e n t^di^^ 
A^rd esSiProt ocols. such asjSlueSi'ptn ; IEEE wireless local 
areanetvrark^LAN) standard 802.11, and infrared. Intra- 




vehicle interface 136 is capable of' sborrTangewi reless 
communications, via wireless link 161^~With other wireless 
d evices 138 and ,^^cj SQrs^ 40 of any type, for example, 
* wifeless telephones,' computers, pagers, PDA's, entertain- 
\ ment devices, prmteK._ fax^ 

^^'^ofks^ as ^lu'e to^o t ^™ ^ " ^^'l cle sensors, ve hide 
^ actuatoi^^^^hickjfls^ amj^^lilce. In addition, intra 
eiuci^ intelSc£^136**can^ to communicate with 

re less devices that are physically outside the vehicle but 
close to the vehicle, such as a service station kiosk. One or 
more wireless devices 138 can comprise one or more 
antennas such as antenna 162 and communicate via wireless 
link 163. One or more sensors 140 can comprise one or mor J 
antennas such as antenna 164 and communicate via wireless 
link 165. 

In one embodiment, the various components and systems 
in FIG. 2 can communicate with each other via a wireline 
link 135, for example, a power/data/control bus, and the like. 
In another embodiment, some of the various components 
and systems in FIG. 2 could communicate via a wireless 
link. 

FIG. 3 depicts a Incal n^de 106 of an exemplary infor- 
mation appliance system luO. As shown in FIG. 3, the local 
node 106 comprises a ^processor 121 with associated local 
node memory 148. Local node memory 148 comprises local 
node control algorithms 146. Loc^l node memory 148 can 
include, but is not limited to, random access memory 
(RAM), read only memory (ROM), and other memory such 
as a hard disk, floppy disk, and/or other appropriate type of 



node memory 152 can include, but is not limited to, random 
access memory (RAM), read only memory (ROM), and 
other memory such as a hard disk, floppy disk, and/or other 
appropriate type of memory. Regional node 104 can initiate 
and perform communications with other nodes shown in 
FIG. 1 in accordance with suitable computer programs, such 
as regional node control algorithms 150, stored in regional 
node memory 152. 

Regional node 104 also comprises any number of 
transmitters/receivers 177 for transmitting and receiving 
communications via wireless link 171 to and from any 
■L^ number of local nodes 106. Communications are transmitted 
1 and received through an antenna 170. 

Regional node 104 also comprises any number of 
transmitters/receivers 178 for transmitting and receiving 
communications via wireless link 168 to and from any 
number of regional nodes 104, servers 102, and the like. 
Communications arc transmitted and received through 
antenna 169. As shown in FIG, 4, the various components 
and systems can also communicate, via terrestrial links such 
as wireline, radio frequency (RF), or optical links, and the 
like, with other local nodes 106 and regional nodes 104. 

In^OBe^bodiment, the various components and systems 
in I^^^jSan communicate with each other via ^ wireline^ 
link 135, for example, a power/data/control bus, and the like. 
In another embodiment, some of the various components 
and systems in FIG. 4 could communicate 3a_jLJzyipeless 
link. 

In FIGS. processors 120, 121, and 123, respectively, 
perform distributed, yet coordinated, control functions 
within information appliance system 100 (FIG. 1). Proces- 
sors 120, 121, and 123 are merely representative, and 
information appliance system 100 can comprise many more 
processors within the distributed servers 102, regional nodes 
104, local nodes 106, and user nodes 108. 

Processors 120, 121, and 123 can be of any suitable type 
or types, depending upon the functional requirements of the 
overall information appUance system 100 and its constituent 



20 



25 



30 



35 



40 



45 



memory. Local node 106 can initiate and perform commu- 
nications with other nodes shown in tlG. 1 in accordance elements, including servers 102, regional nodes 104, local 



with suitable computer programs, such as local node control 
algorithms 146, stored in local node memory 148 

Local node "106 also comprises any number of 
transmitters/receivers 175 for transmitting and receiving 
communications via wireless link 144 to and from any 
number of user nodes 108. Communications arc transmitted 
and received through antenna 166. 

\ Local node 106 also comprises any number of transmitter/ 
receivers 176 for transmitting and receiving communica- 



nodes 106, and user nodes 108. 

- Processors 120, 121, and 123 comprise portions of data 
processing systems that perform processing operations on 
computer programs that are stored in computer memory 
60 such as, but not limited to, user node memory 128, local 
node memory 148, and regional node memory 152. Proces- 
sors 120, 121, and 123 also read data from and store data to 
memory, and they generate and receive control signals to 
and from other elements within information appliance sys- 
tions via wireless link 168 to and from any number of 65 tem 100. 
regional nodes 104. Communications are transmitted and The particular elements of the information appliance 
received through antenna 167. As shown in FIG. 3, the system 100, including the elements of the data processing 
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systems, are not limited to those shown and described, and interactions between synchronous applications and asyn- 

they can take any form that will implement the functions of chronous notifications and alerts. 

the invention herein described. Logical button manager (LBM) 224 allows an application 

To provide an example of one context in which the present to map logical buttons to actual physical buttons on a user 
invention may be used, a brief overview of a client platform ^ device. It allows physical buttons to be referenced by logical 

and a server platform, together with their associated soft- names. It manages different sets of buttons, such as pre-set 

ware modules, will now be described. The present invention buttons, application buttons, and so on. 

is not limited to implementation by any particular set of Personal information manager (PIM) service 226 supports 

elements, and the description herein is merely represcnta- functions to enhance user productivity, such as an address 

tional of one embodiment. The specifics of one or more jjqqj^^ ^ calendar, a memo management capability, and so 

embodiments of the invention are provided below in sufiS- forth. The address book can comprise information that is 

cient detail to enable one of ordinary skill in the art to up-loaded from a PDA, entered by voice or by keys from the 

understand and practice the present invention. user, down-loaded from the Internet, and so forth. 

Overview of Qienl Platform 15 , ^^^=4^° ^e^i^e 227 provides a variety of trip-planning 

functions, such as route and map retrieval, route-plannmg, 

FIG. 5 illustrates major functional software blocks of a determination of route distance, etc. 

client platform 200, in accordance with one embodiment of Position service 228 provides abstract positioning appli- 

the invention. ArchitecturaUy, the user node 108 comprises nation programming interfaces (API) to support a variety of 

a software-based client platform 200 that supports a wide position-determining mechanisms, such as GPS. differential 

range of applications and services. This provides great Qps^ in-road transmitters, cellular base stations, etc. 

fle^dbility and allows the user platform's feature set to be p^^^^^ ^^.^ ^29 provides server-based profiles for 

readily expanded or updated after the user node 108 has been ^^^.^^J^ ,j ^^^^^ application 

deployed into its intended market. configuration. It can also ensure that user profiles are por- 

These software blocks are computer program modules ^5 table from one user vehicle to another, 

comprising computer instructions, such as user node control j^^^^ ^^^.^^ 230 synchronizes one or more data- 

algonlhms 126, that are stored m a conoputer-readable b^^s on cUent platform 200 with counterpart databases on 

medium such as user node memory 128. These software , .e^^ mn 

J 1 1 . c u J - * ir»u server plattonn 3 UU. 

modules are merely representative of one embodiment of the *^ ■ ^ . ^ • 
invention. In other embodiments, additional modules could ,q I^^bug service 231 provides debug functions to isolate, 

be provided as needed, and/or unneeded modules could be examine, and correct errors m the operation of the software 

^gjgjgj residing on the client platform 200. 

The software blocks include the following modules, each Application manager 232 controls the installation and 

of which is briefly summarized below according to its updating of applications, including security attributes of the 
reference numeral in FIG. 5. 35 applications. 

The client platform software comprises three general User interface manager/media manager 233 manages the 

layers: applications 202, foundation software 204 upon user iiiterface, e.g. what entities can access what portions of 

which the applications 202 are supported, and platform- ^ display screen (in the ca^ of the user interface manager), 

specific software 206. In one embodiment, the upper two ^^""^^^^ ^^P^^^^ audio and video fimctions, e.g. 
layers are implemented in the Java^" programming 40 radio, voice-recx)gmtion, sound clips, etc. (m the case of the 

language, available from various suppliers, including Sun media manager). 

Microsystems, Inc., Palo Alto, Calif. One advantage of the Security manager 234 provides permission and policy 

Java™ programming language is the support of code dis- restraints within the client platform 200. 

tribution in a platform-independent manner. Service framework 235, to which the current invention 

The lowest layer, i.e. the platform-specific software 206, pertains, is responsible for locating, connecting, and con- 

comprises a real-time operating system 208, a virtual trolling services required by applications 202 and other 

machine platform (such as the Java''" 2 Virtual Machine, services. Additional description of the service framework 

available from Sun Microsystems, Inc.) and associated 235 is provided elsewhere herein. 

classes 242, and a native library interface 244. Connection manager 236 manages connection(s) of the 

Referring to FIG. 5, applications 202 can comprise an client platform 200 to one or more networks, such as 

extremely wide variety of informational, safety, query, geographically distributed cellular and server networks. It 

communications, entertainment, and other applications, for ensures continuity of sessions across physical and/or logical 

example navigation 211, weather 212, stocks 213, traflSc network interfaces. It can require security (e.g. 

214, news 215, and others 216 of any type. As used herein, authentication, encryption, etc.) as a precondition to a con- 

an "application" is defined as any computer program that nection. It can ensure that l ow bandwidt h connections are 

provides one or more functions that are of interest to a user used efiBciently. 

of the information appliance system 100. other modules 225 can also be provided within the 

Foundation software 204, in one embodiment, comprises foundation software 204 of the client platform 200, depend- 

the following modules, each of which will now be discussed, ing upon the ftinctional requirements of the client platform 

Selector module 221 launches and controls applications 200. 

selected by the user. It is user-configurable. Platform specific software 206, in one embodiment, corn- 
Abstract user interface (UI) 222 supports a wide variety of prises the following modules, each of which will now be 

input/output (I/O) functions that enable the user to interact discussed. 

with the user device. 65 Power manager 238 provides power status change events 

Focus manager 223 enforces priority-based access to UI to applications, such as "power on", "power off', "sleep/ 

and media resources. Focus manager 223 also controls accessory mode", etc. It can enforce a low-power mode in 
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emergency situations, reserving power to the highest priority 
functions. It can also monitor power consumption to identify 
elements that may be consuming unreasonable amounts of 
power. 

Resource manager 239 manages priority-based access to ^ 
system resources, such as a processor, threads being 
processed, memory elements, and persistent storage. The 
resource manager 239 can ensure the required resources to 
support an emergency call by halting or suspending lower 
priority applications. 
' Vehicle information 240 provides information to support 

primarily missionicriticalj^^ jgijlSLw^^ comprises 
information to coiitrol certairi irTvefuclTISInctions, such as 
r emote door, unlock J t comprises status information from 
^ the m-vehicle system^e^g^^^hioUaritS^eedMt also can 
comprise inforrnafionaerived from integrated vehicle 
components, such as glob^p^^ipning ^information from an 
in^i^hicl^gPS^ystem. 

Other modules 237 can also be provided within the 
platform specific software 206 of the client platform 200, 
depending upon the functional requirements of the client 
platform 200. 

Overview of Server Platform 

25 

HG. 6 illustrates major functional software blocks of a 
server platform 300, in accordance with one embodiment of 
the invention. Architecturally, each server 102 (FIG. 1) 
comprises a software -based server platform 300 that sup- 
ports a wide range of applications and services. This pro- 30 
vides great flexibility and allows the server platform*s 
feature set to be readily expanded or updated after the server 
102 has been deployed into its intended market. 

These software blocks are part of computer program 
modules comprising computer instructions, such as local 35 
node control algorithms 146 (FIG, 3), that are stored in a 
computer-readable medium such as local node memory 148. 
Additionally, or alternatively, they can be implemented as 
regional node control algorithms 150 (FIG. 4), which are 
stored in regional node memory 152. 40 

These software modules are merely representative of one 
embodiment of the invention. In other embodiments, addi- 
tional modules could be provided as needed, and/or 
unneeded modules could be deleted. 

The software blocks include the following modules, each 
of which is briefly summarized below according to its 
reference numeral in FIG. 6. 

The server platform software comprises three general 
layers: applications 302, middleware 350 upon which the 
applications 302 are supported, and enterprise platform 310. 
Enterprise platform 310 comprises software, including an 
operating system, that is specific to the particular server 
platform being used. Diflferent servers 102 can utilize dif- 
ferent server platforms 300. 

Server platform 300 supports an extremely wide variety 
of informational, safety, query, communications, 
entertainment, and other applications 302, for example navi- 
gation 311, weather 312, stocks 313, traflSc 314, news 315, 
and others 316 of any type. The application set supported by 
server platform 300 will typically be much broader than that 
supported by any one client platform 200. 

The middleware 350 of server platform 300, in one 
embodiment, comprises the following modules, each of 
which will now be discussed. 55 

Ad service 322 provides advertising related services, such 
as the availability and location of commercial businesses. 
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Trip plan service 323, PIM service 324, profile service 
325, data sync service 326, security manager 334, connec- 
tion manager 337, and application manager 338 perform 
similar functions to the corresponding modules previously 
discussed with reference to client platform 200 in FIG. 5. 

Usage service 327 provides a logging service that tracks 
the usage of any desired service, module, or other element 
in the server platform 300. 

Access modules 330 each provide a unique entry point for 
users into a corresponding database. Each database in the 
server platform 300 has one and only one entry point in the 
form of an access module 330. The access modules 330 
provide a consistent programming interface to their using 
entities regardless of the underlying database technology. 

Application databases 332 provide a variety of databases 
to support any application required in server platform 300. 
These can include, for example, databases to support 
navigation, personal information management (PIM) func- 
tions such as address books, and the like. 

System databases 333 provide a variety of databases to 
support system functions within server platform 300. These 
can include, for example, profile data, session data, event 
data, and usage logs. 

Service framework 335, to which the current invention 
pertains, is responsible for providing services required by 
applications 302. Additional description of the server plat- 
form service framework 325 is provided elsewhere herein. 

Event manager 336 manages the creation and dispatching 
of server-side events that represent server activities in a 
generic way. 

Call center 340 supports services requested of and 
responded to by a remote call center, such as a concierge 
center. 

Structured query language (SQL) 342 is a database query 
language commercially available from various suppliers, 
including Oracle Corporation, Redwood Shores, Calif. The 
associated relational database management system 
(RDBMS) is a database management system commercially 
available from various suppliers, including Microsoft 
Corporation, Redmond, Wash. 

LDAP (lightweight directory access protocol) server 344 
provides a set of communications protocols for accessing 
information directories. 

HTTP server 346 supports Internet accesses originated by 
a client platform 200 or by another server platform 300 on 
behalf of a client platform 200. 

Other modules 321 can also be provided within the 
middleware 350 of the server platform 300, depending upon 
the functional requirements of the server platform 300. 

Overview of Services 

One purpose of this invention is to provide a system to 
allow a mobile client platform to discover and use services 
that become available dynamically within the client plat- 
form's environment. Many of ±e features of the present 
invention are facilitated by making remote services available 
to a mobile client platform. 

The availability of some of these remote services is based 
on the physical proximity of the remote server to the vehicle. 
These types of remote services are typically accessed via a 

s hort-range wireless | ^nl^,^^]:itJj^^flhli5;hed,whenJh&J^£hicl£. 

comes withi njiajfie. of^ scxy^^ ^ , 
and Whicfi^are lost when the vehicle leaves the immediate 
area. 

Other services, l jioihjocal^ andjce , mot e ,^^^ availab l e 
regardless of ,tbeivehicleisJocaUouaLj^jye'rs' in ine ipjt'ra- 
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struct u re can provide rem ote segic es over lon g ^ra^ 
siTch'^s^eiiuiarTr'aSSRoiSf^^ 

vid gd by devices within the vehicle over short-range links,! 
sucliS'BlueTcJoS?^. Local services may also be provided by 1 
de^J^'tfiat*tr^i're'ctly wired in, such as an odometer or 
digital video disk (DVD). The present invention supports a 
wide^nSraber of interfaces to enable both short-range and 
long-range bi-directional and uni -directionai*co mmumc ^ 

Services arc a fundamental building block of the software 
architecture. They play a variety of roles and are found at all 
levels of the architecture. As used herein, a "service" is 
defined as an encapsulation of some functionality that is of 
use to one or more service-using entities (current or 
anticipated) or that needs to be isolated from the service- 
using entity for some reason. A service may provide access 
to information or perform some computation. Or it may 
provide access to a hardware capability such as a commu- 
nications link or other device. 

A client application typically uses a set of services to 
provide the desired functionality to a human user. Services 
are identified primarily based on the interface implemented 
by the service. Service interfaces are abstract and serve to 
insulate the service consumer from the service implemen- 
tation. Services can be further identified based on attributes 
associated with the service. Attributes may be used to 
characterize services and to aid in distinguishing services 
implementing the same interface from one another, such as 
on the basis of cost, performance, and so forth. 

Services can be considered to fall into two broad 
categories, local services and remote services. Local ser- 
vices provide access to functionality that is local to the 
platform such as an on-board GPS device. Remote services 
are offered by an external server, such as a remote commu- 
nications node, and are accessed via a communications link, 
such as a wireless link or interface. 

Consolidator Service — Hidden Services 

A system can have a number of instances of the same 
service. In order to reduce the complexity of using such 
services, a consolidation service can be utilized. This service 
consolidates the underlying services and presents a single, 
unified service to users. The underlying services can be 
declared "hidden", so as to obscure their presence from 
service-requesting entities when performing a service 
lookup. 

These services can be explicitly located by specifying that 
"hidden" services be included in the search. The service 
framework 235 provides access to a hidden service only if 
the service-requesting entity explicitly specifies that "hid- 
den" services should be considered when performing the 
lookup. When this is done, and access is provided to a 
hidden service, the existence of the service is disclosed to 
the service-requesting entity. 

Private Services 

The exposure of a service on a client platform to external 
communications nodes is controlled by declaring the service 
"private" or not. Most services on a mobile client platform, 
e.g. stock portfolio or personal address book, would be 
private. However, some services may be visible to an 
external communications node. For example, a juke box 
service could be visible to a home entertainment system 
and/or personal computer when a mobile client platform is 
parked at home, but it could be invisible when it is away 
from home. Any service that needs, as part of its normal 



function, to be accessed by an external communications 
node, particularly where the access is also initiated by the 
external communications node, would be non-private. 

A service can have any of four possible combinations of 
"hidden" and "private" attributes, as shown by Table 1 
below: 

TABLE 1 

Security 



15 



20 



25 



35 



40 



"HiddcQ" 


"Private" 


Result 


No 


No 


Service is visible locally and externally. 


No 


Yes 


Service is visible locally but not externally. 


Yes 


No 


Service is visible locally and externally only if 






"hidden" is explicitly specified on lookup 


Yes 


Yes 


Service is visible locally only if "hidden*' is 






explicitly specified on lookup; service ts not 






visible externally. 



The above-described "hidden" and "private" attributes 
determine whether or not a service can be exposed to 
internal and/or external entities. Additionally, a suitable 
security check is made prior to providing access to the 
service by internal and/or external entities. The security 
check is performed using appropriate access controls, e.g. 
certificates. Access is granted only to those services and 
applications having proper authorization. 

Representation of Remote Services through Local 
Proxy 

In order to simplify things for the entity using the service, 
it is desirable for remote services to appear exactly like local 
services from the perspective of the user platform. One way 
to accomplish this is to represent each remote service as a 
local service through the use of a local proxy. This proxy 
insulates the service -using entity from the complexities of 
communicating with the remote server. It also unifies the 
access methods. The same methods are used to access a 
remote service as are used to access a local service. This is 
useful should a remote service become available that is in 
some way superior to a corresponding local service. An 
application using the local service could switch to the 
remote service and use it just like the local service. 



Service Components 

A major benefit of using services is the flexibility derived 
from the abstraction of the functionality performed by the 
service. Every service comprises two basic components: the 

50 service interface and the service implementation. The ser- 
vice interface comprises details concerning the methods and 
variables that the service exposes in order for some service - 
requesting entity, such as an application or another service, 
to make use of the service. The service implementation 

55 comprises details concerning the implementation of these 
methods as well as any additional, internal methods. In order 
to use the service, only the interface need be known. The 
details of the implementation are hidden and of no interest 
to the using entity. This allows the implementation to change 

60 without impacting the using entity (so long as the interface 
is preserved). 

Service Framework — General 

In a distributed wireless information appliance system 
65 100, such as that disclosed herein, a rendezvous mechanism 
is required to allow services to advertise themselves and to 
enable potential service-using entities to locate them. The 
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service framework provides such a mechanism. The service cation of service events. Such events may be used to inform 

framework is a facilitator that provides a standard, simple the client of a service becoming available, becoming 

way for services to make themselves available and for unavailable or changing in some way. 
service-using entities to locate the services that they are 

interested in. It provides an organization or structure for 5 Service Framework Architecture 

services lhai results in a unified and consistent view of the According to one embodiment, the service framework 

services 

includes a service registry, a local service lookup function. 

For example, the detaHs of obtaining navigation informa- ^ ^^^^^ ^^^-^ ^^^^^ function. The local and remote 

tion from a gas station kiosk versus an Internet navigation ^^^^^ functions also include an asynchronous notification 

server via a cellular data link when on the highway will be lO function. Although the architecture is symmetrical, the nor- 

very different. The applicaUon docs not have to concern ^^^1 behavior is asymmetrical. In normal operation, the 

itself with these details. It is pnmarily mterested in gettmg ^^^^^^^ ^^^^^^ ^^^^^ ^^^^ ^ ^^^^^ ^^y^ ^-^^ the servers 

the navigation mformation. Implementmg this functionality ^^^-^^ ^^^^^^ Jq^^i services can be designated as 

as a separate service rather than incorporating it in the "private", making them invisible to entities off the client 

application itself isolates the application from the details of 15 pj^jf^j.^ 

the implementation and also provides flexibility in dealing „ . . . • r , i 

with facilities that are similar but different. It also provides ^ Trt-e service registries are repositories for local services. 

I,. 1 ... e- |., Faculties are provided to add services to, remove services 

multiple applications with access to the same functionality - j • -.i.- *i_ ■* o . • 

tr ■ . *i. * ™ ■ from, and alter services withm the registry. Support of basic 

in an efficient manner that conserves memory, commumca- , . r ■ ■ ^ j t-L u 

. hfe-cycle management functions is provided. These can be 

tions bandwidth, and processing resources. 20 . . . . u-i-* i-u u 

. ^ ' used by services to provide a hot upgrade capability. The old 

The service framework provides a way for services to ^^^^^^^ ^^^^^^^ gracefully switched after the 

announce their availability. Services register themse ves j^^^^^^j ^^^^^ ^ transferred, completely transparently to the 

with the service framework. Services de-register themselves subscribing services and applications, 

when they become unavailable. , r 1 1 j 

^ . . , . . ,25 From the perspective of a service consumer, local and 

nie pninary way in which a service is identified and y^^^^, ^^^^^^ 

selected 1^ based on the type of the service, i.e. the classes ^^^^^^ j ^ ,^ j^^jy j^^, ^„3„,i. 

and interfaces that comprise the service. Services that are ^^^^ ^ potentially Urge number of remote lookup services 

similar in this respect require a way to distinguish them- ^^^^ j, ^^j^^^ represented by a small local 

selves from one another. This is accomplished using p^xy (also referred to herein as the "remote service fron- 

attribute sets. Each service may optionally specify a group ^^^^^ j^^^ ^^^^^^^^ ^„ 

of attribute set objects that further charactenzes the service. ^j^^j ^^^^^^^ ^^ ^ ^^^^^^ provisioning mecha- 

An example of such an object is a service information object ^^^j^,^^ dynamically load code in the 

that specifies the service vendor, version identifier, elc^The g^,^ .j^;^ j,^^^^^ ^^^^^ „f ,1^^ availability of the 

service framework allows the service to alter these attnbutes ^^^^^^ ^^^^^ ^^^^ ^j,^^ establishing communications with 

while mawtammg its registration. ^g^j^^^g ^^i^^ i, ^gj^j^^g -^^^^ ^^^^ geivice- 

Altribules provide a potential user with a way to refine ^i^jng entities on the client platform wishing to make use of 

service selection beyond just the service type. Different th^ service do so through the proxy and are unaware of the 

implementations of the same service can be distinguished existence of the remote component, 

from one another through the use of attributes. For example ^ ^o^^, ^^^^^ ^presenting remote services are provided 

there may be some charactenstic of a service (such as cost ^^^^.^^^ capabilities not available to normal services 

or performance) that may be valuable to the user when , „ i-u i**- -a 

, ^ . ^ . , or service consumers. These facilities provide access to 

selecting one service over another. * i i • ^ n »u * i * 

^ remote lookup services and allow the proxy to locate its 

The service framework provides a way to resolve depen- ^.^j^ote counterpart. These lookups are performed just-in- 

dencies. Services may be employed by other services and 45 ^ minimize the caching of remote service 

not just by applications. It is possible that a circular depen- information locaUy. Proxies can request asynchronous noti- 

dency loop is formed amongst a group of services. A fication of a remote service becoming available. Such 

deadlock may arise ifeach service registers only after It has requests are resolved as a batch when a remote lookup 

successfully located all services upon which it is dependent. ^^^-^^ becomes available to reduce the demands on the 

Attributes may be used to avoid such a situation. Dependent 50 communications medium. 

services proceed to register themselves but include an . . • u n -u . ■ * a 

-u . J- • 11.1 TT-' Remote services inhent all attributes associated with Its 

attribute indicating the service is unavailable. This exposes . , . ™. ^ u- u- 1 • e 

. , ^ • * u J J ♦ lookup service. This supports a hierarchical organization of 

the service to any other services that may be dependent on • . • 1 • . • • 1 1 

„ • u 1 . J 11 • M - J -J . services that is useful in CO nstraimng lookups, 

it. Once the service has located all services it is dependent ° 

on, it may alter the attribute to indicate the service is now 55 Language independence is achieved by implementing the 

available underlying remote service support using a language inde- 

™ . c 1 J e • pendent service location technology. The local proxies are 

The service framework provides a way for a service-using ^ , , . . ... 1 

. ,t,^ 1- ^f. i^^ir able to locate their remote counterpart in a language mde- 

ent It V, whether an application or another service, to look up . r i - 1 -n 1 1 t x«i j • 

. ™. • p • . , ' A -u ^ • . «p -tr. pendent fashion but still present a local, Java^-based view 

a service. The service of interest is described in terms of f . - 

type and possibly also attribute set values. On a successftil 60 ° ^ ^ service. 

match, the service framework provides the caller with an The system imposes a set of mandatory methods to be 

object containing a reference to the service object. The caller implemented by aU services. These include methods to 

can invoke the service via this object. support life-cycle management functions. 

The service framework provides a synchronization Overall, the service framework architecture supports 

mechanism to allow services and their service-using entities 65 security, performance, and ease of use. 

to come up in any order with respect to one another. Since, in one embodiment, the present invention is imple- 

Service-using entities may register for asynchronous notifi- mented in a vehicle-based information appliance, such 
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appliance needs lo be as reliable as a car radio. In addition, interface into the service firamework lo support the discovery 

security is of utmost concern. The suppliers of automotive of the remote service backends. This interface is hidden 

original equipment manufacture (OEM) equipment typically from applications. 

prohibit the downloading of software onto a vehicle-based framework requires that all services imple- 
information appliance. My software to be installed on the 5 ^^^^ ^ ^^^-^ interface. This interface declares a number of 

customer platfonn must first be oertified Even software that ^.^^atory methods that support fimctions such as life-cycle 

has passed certification can only be mstalled on the platform j ft- 

by an authorized installer. These restrictions preclude the managemen . 

dynamic downloading of service proxies as is done by prior Services may invoke other services. If a service is unple- 

art connection technologies, such as the Jini™ connection mented to act solely as an aid to other services, it may be 

technology. tagged as being "hidden". The presence of such "hidden" 

The service framework addresses this through the use of services is obscured from applications. They are located 

distributed remote services. Every remote service comprises only by expliciUy specifying that "hidden" services be 

two portions: a frontend portion and a backend portion. The included in the lookup, 

service frontend or local proxy is installed on the client d * c ■ r Ln 

platform. The service backend resides on the server provid- R^motQ Service Lookup 

ing the service. The proxy can request asynchronous noti- FIG. 7 illustrates a simplified block diagram showing 

fication of a remote service becoming available. The service various components of a service framework 235, in accor- 

framework only looks for the service backend when the dance with one embodiment of the invention. The service 

proxy has requested the service. When the service frontend framework comprises a service registry 250, an event deliv- 

discovers the service backend via the service framework, the ery daemon 252, a service event notification registry 254, a 

two halves effectively coalesce, resulting in a fully formed remote service event notification registry 256, a remote 

service that is made available to service-using entities. lookup daemon 260, one or more remote lookup service 

Service-using entities invoke the service through the service frontends 261-263, a proximity daemon 264, and a service 

frontend, which communicates with the service backend to framework interface 270 that includes local portion 272 and 

carry out the service. No code is downloaded to accomplish a remote portion 273. Service registry 250 contains entries 

this. No effort is made to locate the remote service until a representing both local services as well as remote or dis- 

request to do so is made by the service frontend (i.e. the local tributed services. Service registry 250 is a data object that 

proxy). fiinclions as a repository of service entries. Using service 

Since all remote services are represented by a local registry 250, applications can perform a lookup for a desired 
service frontend, loss of communications with the service service, specifying the type of service (using one or more 
backend due to a fault or mobility can be detected by the Java''" classes defining the service interface of interest, e.g. 
service frontend. The service frontend can respond by position devices, network access devices, etc.), and option- 
de-registering the service. This obviates the need for a ally attributes. 

leasing mechanism such as is provided by the known Jini*^" As mentioned above, services typically comprise two 

connection technology and simplifies the job of a service parts: an interface to the service and an implementation of 

writer. the service. These are packaged as two distinct things. The 

Also in the interest of security, the service framework implementation of the service can be changed without 

supports an asymmetrical view of services. Local services affecting the interface. 

may be tagged as being "private" to prevent their advertise- 4Q The service event notification registry 254 is a data object 

ment to external lookup servers. within the service framework in which notification requests 

The service framework also handles remote services in a arc stored. Notification requests can originate from services 

manner that conserves memory and reduces the load on the as well as applications. Notification requests include the 

wireless communications pipe. Whereas, the Jini™ connec- type of service (using one or more Java™ classes defining 
tion technology suggests that services register themselves 45 the service interface of interest, e.g. position devices, nct- 

with all lookup servers belonging to the same group irre- work access devices, etc.), a reference to the entity (e.g. 

spective of demand for the service, this could overwhebn an application or service) that issued this service request, the 

information appliance both in terms of memory usage and service events of interest (e.g. match, no match, change), and 

communications traffic. The service framework does not optionally attributes. If an application says "tell me when a 
over-populate its local registry with entries representing all 50 service XYZ becomes available", a notification request is 

available remote services. Instead, it performs just-in-time stored in service event notification registry 254, This applies 

lookups by invoking the remote lookup service itself on an to both local and distributed (remote) services. When a local 

as needed basis. Successful lookups return information that service (not shown)or a service frontend 281 registers, 

is required to communicate with the remote service. This unregisters, or alters its attributes with the service frame - 
information is propagated to the interested entities by the 55 work 235, the service framework 235 will look at the service 

service framework but is not otherwise cached. Memory event notification registry 254 to determine whether a noti- 

utilization is minimized, and the bandwidth is used fication request for this service has been registered as 

efficiently, since all of the traffic is demand driven. requested by a service-requesting entity, such as application 

In the interest of simplicity, the service framework pre- 268. If there's a match, the event delivery daemon 252 is 
sents all services, whether local or remote, as local services 60 invoked to dispatch the event to the entity, such as applica- 

to the application. The service framework provides a single tion 268, interested in that service. 

consolidated lookup service that can be used by applications Remote service event notification registry 256 is analo- 

10 locate any service. Any remote lookup services that gous to service event notification registry 254, but it only 

become available are handled internally by the service deals with the backend of a distributed service. When a 
framework and are not exposed to applications. 65 service frontend 281 (also referred to herein as a "local 

Remote service frontends, however, are aware of the proxy"* or "remote service proxy" and discussed in greater 

local/remote distinction and are provided with a special detail below in the section entitled "Remote Service Dis- 
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covery and Connection**) puts in a request for a remote communicates with the remote service backend to imple- 

service, that request is stored in remote service event noti- meal the service. 

fication registry 256, Remote service event notification 3^^^ Location-Setup 
registry 256 contains similar information to the service event 

notification registry 254, but remote service event notifica- 5 The operation of one embodiment of service framework 
tion registry 256 only contains information relating to 235 wiU now be explained in terms of how a service- 
remote service backends. requesting entity, such as application 268 requests and 

n. • . J 'ycA ' ' * 4 A- locates a remote service. In this scenario, an application 268 

Proximity daemon 264 is mteresled m communications , ^ - . c • . . ■ u • l • 

V I u \ ^ A 4 •♦JT-u™- attempts to locate a pomt of interest (POI) service, which is 

hnks being completed or termmated. The connection man- *^ _, . ^ • ^ « • 1. • . 

- ^cl ' •* J ♦ « in assumed to be a remote service. The order m which the 
ager service 266 comprises a proxunity-detecting program 10 ^ ..... , 
J , ^ . \.a r c • • *^ actions are presented is not cntical. 
module that sends a notification or a communications inter- r • t- - t - c 
face coming up or going down to the proximity daemon 264. ^^^0^^ ^ service or application can use the service frame- 
When an interface comes up, the proximity daemon 264 ^^^^ 235, it must obtain a reference to the service frame- 
creates an instance of the remote lookup service frontend, ^^rk 235. This is done through a static method. This method 
such as remote lookup service frontcnd 261, 262, or 263 and i5 provides an object that implements the external interface 
informs it of the connection detaUs. 270 to the service framework. This interface is used to 
Assuming in this case that remote lookup service frontend P^^^^"" ^^'T^f T''''' ,^°^Sister. and alter 
261 has been created, it tries to communicate with its '^^^^ ^^"^^^ ^^^^ notification 

corresponding remote lookup service backend. The remote ™ * . . 

lookup service frontend searches for a remote lookup service 2° Th« application 268 constructs a template describmg the 

backend by broadcasting or multicasting for a response from " mterested m e.g. the POI semce. This template 

a listening remote lookip service backend. comprises an array of classes and mterfaces to implement 

,. . , . ... • 1. 1 J J -i: ,1. the service, plus an optional array of attnbute sets thai 

If It locates as remote lookup service backend. and if the ^^^^^^ ^^^^^^ 1^^^ 

remote lookup service frontend determmes that it is com- ^^^^^^ .^^^^^^^ jTO and into the service framework 

patible with the remote lookup service backend, the remote „a,vu ^^.„;„^c ^^^-ct^, f^r ^ 

r , . - ^ X 111 235 which internally exammes the service registry 25U tor a 

lookup service frontend notifies the remote lookup daemon ,„u:„„ t« tu^ ^,^^»t oft^r iu^ ^^rr,ir>^ 

- *L . .11 J '^iin A matching service. In the current example, arter the service 

260. There is one remote lookup daemon 260, and it can . ^ 2_n ■ •* * n • a- *■ 

7 „ , . , , . . r 1 . registry 250 IS examined, It returns a null mdicatmg a service 

handle multiple remote lookup service trontends such as _° ^ . . . . f„„„j 

, , ^ - K ^r-t matching the template was not lound. 

remote lookup service trontends 261-263. tt , • ft. . .t. . r ^ i- 

, , , , , 30 Upon learning that the service was not round, the appli- 

Remote lookup daemon 260 performs a lookup on any ^^^^^ ^^^^^^ ^ ^ ^^^^^^ 3^^.^,^ 

notification requests pendmg in the remote service event ,^,ii,bility. The same template is passed via arc 283 and 

notification registry 256, batchmg them within the remote ^^^^^^^j .^^^^^^^ 270 into the service framework 235, this 

lookup daemon 260 and It sends them to the remote lookup requesting notification. In addition, a service event 

service frontends 261-263 that found a compatible remote 35 ^^^^^^^ ^ ^^^^.^^^ ^ j.^ ^-^^^ ^^^.^ 

lookup service backend. The remote lookup service fron- f^^j^ework 235. The listener specifies the method to be 

tends 261-263 pass the information across the interface to ^^voked when the event occurs. The transition mask controls 

the remote lookup service backend, which looks for a ^^^^^ semantics and, in this case, is set to generate an 

service backend in a backend service registry on the remote ^^^^^ ^^^^ ^ ^^^^^ ^^^^ ^^^.^ framework 235 

communications node. The remote lookup ^rvice backend ^^^^^^ .^^ ^^-^ ^^^^^ notification registry 

replies with each of the requests, whether it found a suitable ^54, and a registration object is returned to the application 

match or not. For matches, the remote lookup service 268. This object can be used subsequenUy to cancel the 

backend also obtains the parameters necessary for the ser- request 

vice frontend to communicate with the service backend. • a- -a ^ * ■ e * a ,u u 
^ . , J. . r I- individual remote service frontends go through a 
The responses, mcluding the parameters for any matches, 45 ^^^^^^ sequence attempting to locate their rcspeaive remote 
are delivered to the remote lookup daemon 260 via the ^^^^ backends. These services use a different service 
remote lookup service frontend. If a match is found, the framework interface from the one used by the application, 
remote lookup daemon 260 tells the remote service event j^^^ ^^^^^^^ ^^^^^^ framework interface 
notification registry 256 to dispatch the match (i.e. which supporting remote services 273. Each remote service fron- 
entry matched) to the event dehvery daemon 252, and from 50 performs a lookup via arc 284 through interface 270 to 
there a dispatch is sent to a service frontend, such as service ^^^^^^ j^^j^p ^^^^^^ which looks for a correspond- 
fro ntcnd 281. remote service backend. Since, assuming for the current 
The listener extracts the parameters and establishes a example, there arc no remote lookup services in proximity 
connection to the remote service backend. The remote ^t this time, all of these lookups fail and return null, 
service frontend and remote service backend communicate 55 as was done by the appHcation, the remote service 
to determine whether they are compatible. If so, the remote frontends then register requests to be notified of the remote 
service frontend registers the combmed service (i.e. remote ^^^j^ backends* avaUabiUty. The manner in which this is 
service frontend and remote service backend) as a remote ^^^^ ^ identical to that followed by the service- 
service with the service registry 250 of service framework requesting entity in registering a notification request in the 
235. This registration is for the distributed or remote service. 60 service event notification registry 254. However, in this case 
The service framework 235 checks the service event it results in a request via arc 284 through interface 270 to the 
notification registry 254 to see if there are any pending service framework 235, which caches the request in its 
requests for this particular service, and if it finds one, an remote service event notification registry 256. 
event is dispatched by the event delivery daemon 252 to the . . 
requester, such as application 268, informing it of the 65 Service Location-Completion 
availability of the service. The application 268 can then At some point in time, the client platform 200 (FIG. 5) of 
invoke the service, whereupon the remote service frontend user device 108 (FIG. 1) comes in proximity of a place 
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conlaining remote services, such as a local node 106, and a POI service backend. If the POI service backend is deier- 

short-range wireless communications connection or link is mined to be compatible with the POI service frontend, the 

established between the local node 106 and the client POI service is fully formed. The POI service frontend 

platform 200. This causes the proximity daemon 264 of the registers the POI service via arc 285 with the service registry 
service framework 235 to be notified. The proximity daemon 5 250 of service framework 235. This results in the POI 

264 is an internal component of the service framework 235 service being added to the service registry 250. 

that is created during startup. It requests to be notified of the On this registration, the service framework 235 examines 

establishment of a connection on any platform communica- its service event notification registry 254 for notification 

tions interface. This request is serviced by a component requests that arc satisfied by this registration. The listener 
external to the service framework 235, i.e., the connection lO associated with the application waiting for the POI service 

manager service 266. is invoked and sent an event announcing the availability of 

When the proximity daemon 264 receives notification of the service. This event provides the application with a 

a new connection, it instantiates a remote lookup service reference to an object implementing the POI service 

frontend, such as one of remote lookup service frontends interface, namely the POI service frontend. 
261-263, and passes it the particulars of the connection. This 15 -p^jg application then invokes the POI service methods, 

remote lookup service frontend 261-263 differs from other and the POI service frontend communicates with the POI 

remote service frontends in that it docs not use the service service backend to carry out the requests, 

framework 235 to locate its remote lookup service backend. ^ o • T^- j ^ 

Rather it sends out either a multicast or broadcast soliciting ^^^^^^^ Service Discovery and Comiection 
a response from a listening remote lookup service backend. 20 The service framework provides a mechanism by which 

If there is no response, retries are sent at periodic intervals. remote services can be discovered and connected. Remote 

These continue until the remote lookup service frontend is services can register with the service framework through a 

instructed by the proximity daemon 264 to exit, e.g., if the remote service frontend 281 (FIG. 7), also referred to herein 

platform. moves out of range of the local node 106. as a "local proxy" or a "remote service proxy". Remote 

If, however, a response is received, the remote lookup services are also unregistered by the remote service frontend 

service frontend and remote lookup service backend 281, when their remote service backends become unavail- 

exchange parameters and verify that they are compatible able. Thus, the service framework provides a way for 

with one another. If so, the distributed remote lookup service client-platforai based service-using entities, whether an 

frontend 261-263 is fully formed and is registered via arc application or another service, to discover and connect to a 
285 through interface 270 with the remote lookup daemon ^° service, whether it is a local service or a remote service. 

260. More specifically, when a service is requested from a 

The remote lookup daemon 260 is another internal com- remote server, a remote lookup service entity on the client 

ponent of the service framework 235. It is responsible for platform, known as a remote lookup service frontend, 

dispatching remote lookup requests to whatever remote attempts to find its counterpart on the remote server, known 

lookup services happen to be available. as a remote lookup service backend. If a remote lookup 

On receipt of the remote lookup service registration, the ^^^^ Backend exists this service becomes available to the 

remote lookup daemon 260 sets out to see if it can resolve service framework and can be employed to perform lookups 

any of the pending notification requests for remote services. remote service backends. 

The remote lookup daemon 260 accesses the remote service 1^ remote lookup service backend finds a requested 
event notification registry 256 containing these requests. service in its server-based registry of remote service 
The remote lookup daemon 260 delivers these to the remote backends. it returns the parameters to the client-side remote 
lookup service frontend 261-263. The remote lookup ser- service frontend that are needed to establish communica- 
vice frontend 261-263 asks a remote lookup service back- ^ons with the server-based remote service backend. 
end on the remote server to perform the actual lookup by If the remote service frontend determines that it is corn- 
looking for the remote service backend on the remote server, patible with the remote service-backend, the remote service 
e.g. in a backend service registry on the remote server. frontend registers itself as a remote service with the service 

For each lookup request received by the remote lookup framework on the client side, 

service backend. it determines whether the specified service This will be explained in further detail regarding FIGS. 9 
exists in its registry of service backends. If it does, the 50 and 10 below. However, first a local service-locating opera- 

parameters required to establish communication between the tion will be discussed with reference to FIG. 8. 

remote service frontend and remote service backend are FIG. 8 is a diagram depicting a local service lookup 

returned to the requestor. In the current example, the point operation as performed by service framework 235, accord- 

of interest (POI) service backend is found, and the param- ing to one embodiment of the invention, 
eters pertinent to this service are returned to the remote 55 In FIG. 8 three entities are depicted: an application 180, 

lookup daemon 260 via the remote lookup service frontend. a service ABC 184 that application 180 is interested in and 

On receipt of the successful lookup response, including is requesting, and service framework 235. In this case 

transfer of parameters, the remote lookup daemon 260 service ABC happens to be a local service, i.e. one that is 

generates an event to notify the POI service frontend of the resident on the client communications platform, 
existence of its remote counterpart. This event carries the 60 In arc 191, application 180 puts together an object 

parameters that the POI service frontend will need to com- describing the service ABC that application 180 is interested 

municate with the POI service backend. in, and it passes that object into service framework 235 to 

The listener (within the remote service event notification have service framework 235 perform a lookup. 

regisU7 256), that the POI service frontend specified when In arc 192, service framework 235 responds to application 
it registered the notification request, is invoked and is passed 65 180 either that it found service ABC or it didn't find it. 

the event. The listener extracts communication parameters However, for the purposes of this illustration, it is assumed 

from the event and uses these to establish a connection to the that service framework 235 hasn't yet found service ABC. 
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In arc 193, application 180 sends a noiificalion request to 
service framework 235 to notify application 180 when 
service ABC comes into existence. 

In arc 194, after the passage of some time, it is assumed 
that service ABC is instantiated. 

In arc 195, service ABC is registered with service frame- 
work 235. As part of that registration, service framework 
235 determines that this service ABC satisfies the service 
request from application 180 

In arc 196, service framework 235 notifies application 
180 about service ABC. The notification comprises all of the 
information that application 180 needs in order to utilize the 
service 

In arc 197, application 180 invokes service ABC. 

HG. 9 is a diagram depicting the initiation of a remote 
service discovery operation as performed by the service 
framework 235, in accordance with one embodiment of the 
invention. The service framework 235 extends the service- 
locating function described in FIG. 8 to remote services, and 
it handles service location and connection in a way that has 
several advantages, particularly for mobile platforms. 

In FIG. 9, the portion above dashed arrows 275 contains 
entities located on the client platform, and the portion below 
dashed double-headed arrows 275 contains entities located 
on a remote server. The dashed double-headed arrows 275 
extending between the client and server portions represent 
the fact that the client and server are not currently in 
proximity to each other. 

In FIG. 9, operations represented by arcs 289-295 can be 
performed in various orders, and they are not necessarily 
limited to any sequence that is related to the choice of 
reference numbers. 

In arc 289, apphcation 268 puts together an object 
describing the service XYZ that application 268 is interested 
in, and it passes that object into service framework 235 to 
have service framework 235 perform a lookup. 

In arc 290, service framework 235 responds to application 
268 either that it found service XYZ or it didn't find it. 
However, for the purposes of this illustration, it is assumed 
that service framework 235 hasn*t yet found service XYZ. 

In arc 291, application 268 sends a notification request to 
service framework 235 to notify application 268 when 
service XYZ comes into existence. 

In arc 292, service framework 234 performs an implicit 
request for notification of a remote lookup service. 

In arc 293, the remote service frontend XYZ 281 requests 
notification of the remote service backend. 

In arc 294, the service framework 235 requests notifica- 
tion of any interface state changes observed by the connec- 
tion manager service 266. 

Meanwhile, on the remote server, in arc 295 the remote 
service XYZ backend 282 registers itself with the remote 
lookup service backend 265. This registration can be made, 
for example, into a backend service registry on the remote 
server. 

FIG. 10 is a diagram depicting the conclusion of a remote 
service discovery operation as performed by the service 
framework 235, in accordance with one embodiment of the 
invention. 

As represented by arrow 390, the client platform comes 
into proximity to the remote server. 

In arc 391, the connection manager service 266 becomes 
aware of the proximity of the client platform to the remote 
server, and it notifies the service framework 235 of the 
change of state to "connected". 
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In arc 392, the service framework 235 instantiates an 
instance of the remote lookup service frontend 261. 

As represented by double-headed arrow 393, the remote 
lookup service frontend 261 attempts to communicate with 
5 its counterpart (remote lookup service backend 265). 

Assuming the interchange of parameters is successful, in 
arc 394 the remote lookup service frontend 261 registers 
itself with the service framework 235. This registration 
represents the remote lookup service frontend and service 
10 backend as one unit. 

In arc 395, as part of the registration, the service frame- 
work 235 invokes this new remote lookup service backend 
265 to search for any pending remote services, in this 
example, the remote service XYZ backend 282 of the 
15 desired service XYZ. In this example, it is assumed that 
remote service XYZ backend 282 is found, and that the 
parameters necessary for remote service XYZ frontend 281 
to communicate with remote service XYZ backend 282 are 
obtained by remote lookup service frontend 261, 
2° In arc 396, also as a part of the registration, the remote 
lookup service frontend 261 returns (to the service frame- 
work 235) the parameters needed by the remote service 
XYZ frontend 281, so that remote service XYZ frontend 281 
can talk to remote service XYZ backend 282. 

In arc 397, the service framework 235 proceeds to notify 
the remote service XYZ frontend 281 that the remote service 
XYZ backend 282 has been found. The parameters are 
passed along with this notification. 

As represented by double-headed arrow 398, the remote 
service XYZ frontend 281 communicates with the remote 
service XYZ backend 282 over a bi-directional wireless link 
using the parameters. The parameters can include the 
address of remote service XYZ backend 282 (e.g. Internet 
address and port number), version information (if 
incompatible, the service discovery operation could be 
terminated), possibly attributes (e.g. if a printer, the 
capabilities — color, resolution, speed, etc), and so forth. 

In arc 399, assuming the communication was successful, 
the remote service XYZ frontend 281 registers the combi- 
nation service (i.e. remote service XYZ frontend 281 plus 
remote service XYZ backend 282) with the service frame- 
work 235. As part of that registration, the service framework 
235 determines that there is an application 268 that has a 
request pending for this particular service XYZ, 

In arc 400, the service framework 235 notifies the appli- 
cation 268 about service XYZ. That notification provides the 
application 268 with all of the information it needs to make 
use of the service XYZ. 
50 In arc 401, the application 268 invokes the service XYZ. 
The remote service XYZ frontend 281 communicates with 
remote service XYZ backend 282 to perform the requested 
service XYZ. 

From the foregoing description of remote service discov- 
55 ery and connection, it will be seen that application 268 is 
minimally involved in discovering and connecting with 
remote service XYZ. In arc 291 (FIG. 9), it requested 
notification from service framework 235 of service XYZ; in 
arc 400 it was informed of service XY2^ and in arc 401 it 
60 invoked service XYZ. 

In FIG. 10, the service XYZ represented by the combi- 
nation of remote service XYZ frontend 281 plus remote 
service XYZ backend 282 can be viewed as a distributed 
service that has both a local and a remote component. The 
65 local component acts as a proxy for the remote component. 
The service represented by connection manager service 266 
is viewed as a local service. 
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In FIGS. 8-10, the operations represented by the arcs are 
not necessarily ordered in any particular way, and they could 
be performed in a different sequence from that shown. 

Service Framework APIs 

The following is a high level description of the service 
framework APIs and their constituent classes and interfaces. 

The service framework envisions an environment of 
applications and services. In this context, an application is a 
UI -based presentation of a service or a set of services to a 
human user. A service is a reusable application component. 
It may originate as part of an application but migrate to a 
service if multiple applications have a common need it 
satisfies. 

The service framework API set provides several func- 
tions. First, it provides services with a means by which they 
can advertise themselves to potential service-using entities 
(applications and other services). This is done through a 
registration process. 

Secondly, it provides applications and services with a 
mechanism to search for available services. It also allows 
applications and services to request notification should a 
service meeting certain specified criteria become available 
in the future. 

Thirdly, it provides a uniform mechanism for accessing 
both remote and local services. 

The service framework APIs apply to the interface 
between applications/services and the service framework to 
register and discover local and remote services. The remote 
services that are supported require a local proxy or service 
frontend. 

The APIs provide application and service developers with 
a simple yet powerful set of APIs to advertise and locate 
services. 

The following examples typify several scenarios that are 
implemented by the APIs. 

Use Case #1 — Resident Address Book 

The information appliance is configured with an address 
book application that provides the user with an interface to 
the various address books that may be present on the client. 
In addition to the permanent resident address book, transi- 
tory address books may be created and populated from 
accommodated devices such as PDAs, wireless phones, 
personal computers, etc. The application can present the 
contents of these address books to the user as individual 
address books or as a single merged virtual address book. 

Dming system startup, the service representing the resi- 
dent address book is registered. Although this service is 
created very early in the startup sequence, it is able to locate 
the service registry 250 (FIG. 7) and successfully register 
itself with it. 

The address book application starts up and issues a query 
to the service registry to determine what address book 
services are currently available. It is informed of a single 
service — the resident address book. Upon examination of 
the service's attributes, the application determines the ser- 
vice is permanent so notification of status changes is not 
required. The application then obtains a reference to the 
service in order to access its entries. This interface is used to 
inform the application of any additions or deletions. 

Use Case #2 — ^Accommodated Device Address 
Book 

In order to incorporate any address books thai may 
become available from accommodated devices, the address 
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book application registers a notification request with the 
service framework 235 which adds the request to the service 
event notification registry 254. This request states that the 
address book apphcation be notified of any address book 

5 service registrations. 

The driver powers up his PDA and begins transferring the 
addresses of the various sales calls he needs to make that day 
into the information appUance via a wireless link. The first 
address is received by the object exchange protocol module 

jQ associated with the wireless interface being used and is 
recognized to be an address book object. The module learns 
from the discovery module in the protocol stack that the 
device is named "Jack's PDA". Since this device is regis- 
tered in the information appliance's configuration, user 
authentication is not required. The registry is queried to see 
whether an address book service with a name attribute equal 
to "Jack's PDA" already exists. It does not, so the object 
exchange module creates the service with the single entry 
received so far and registers it. This service also has an 
attribute indicating it is a transient service. 

The address book application receives notification about 
the new address book. It obtains a reference to the service 
and incorporates its address book entries for presentation to 
the user. Although the implementation of this service differs 
from the resident address book (Use Case #1), the apphca- 
tion interaction with it is identical due to the use of a 
standardized interface. 

The apphcation examines the service attributes and uses 
the name "Jack's PDA" in the user interface. It also notices 
the transient attribute. This causes the apphcation to request 
notification of when the service is no longer available. 

The information appUance is configured to expire address 
books associated with accommodated devices after some 
period of time. When this time has elapsed, the "Jack's 

35 PDA" address book service is unregistered. The address 
book application is notified of this and removes entries that 
it had tagged as belonging to the now departed address book 
from its internal representation and updates the user inter- 
face accordingly. Since the application had registered a 

40 blanket request to be notified of any address book becoming 
unavailable, it now cancels the request. 

Use Case #3 — ^Authenticated Address Book 
The passenger powers up her PDA to provide some 
additional addresses. The PDA is detected by the informa- 
tion apphancc. Unlike the driver's PDA, this one is not 
registered in the information appliance configuration and 
requires user authentication. The address book service cre- 
ated to represent this device performs the authentication. 
Only if the authentication was successful does it register the 
service and allow the transfers to proceed. It is the service 
itself and not the service framework that is responsible for 
the authentication. 

Use Case #4 — Address Book Restricted by Security 
55 Policy 

The passenger has a huge address book on her PDA and 
inadvertently initiates a transfer of its entire contents. 
Addresses proceed to be transferred into the information 
apphance until the service's storage quota is reached. 
^0 Attempts by the service to store additional addresses fail. 
This quota is enforced by the entity responsible for the 
runtime management of applications and services. 

Use Case #5 — Remote Service Provided by a Local 
^5 Node 

The driver receives a lengthy email while on the road. 
Since it is getting close to lunch, the driver configures the 
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information appliance to look for a restaurant of a specific 
fast food chain that has a print service. He would like to read 
the email hardcopy while eating. As he comes within range 
of a restaurant belonging to the desired chain, a lookup is 
performed and indicates both criteria are met. He pulls in, 
has his email printed, and has lunch. 

Use Case #6 — Client Service Advertisement 

Two families are driving to an amusement park together 
in two separate cars. Each car has an information appliance 
with a "walkie-talkie" service and an application that sup- 
ports voice communication. Since the cars are traveling 
close together, the information appliances are able to com- 
municate via a wireless interface. Both devices were con- 
figured in terms of security rights prior to departure. 
Suddenly, an emergency rest stop situation arises in one car. 
The driver invokes the "walkie-talkie" application to let the 
other car know they need to pull over. To do this, a service 
in one client device discovers and makes use of a service in 
another client device. Another car equipped with an infor- 
mation appliance passes them. As it passes, it joins the 
wireless network formed by the two original cars. The 
passing car attempts to perform lookups on the two other 
cars but doesn*t find anything. Services are not advertised to 
it. 

Use Case #7 — Consolidated Address Book 

The information appliance is configured to present a 
consolidated address book to the user. In this configuration, 
an address book service that aggregates various address 
books registers itself with the service framework 235. It also 
registers a notification request with the service framework to 
be notified when a hidden address book service registers. 
The resident address book service and address books asso- 
ciated with accommodated devices register with the service 
framework as hidden address book services. The consoli- 
dating address book service is informed of these services 
* and proceeds to incorporate their entries into the consoli- 
dated address book. When the address book application 
performs a lookup via the service framework for address 
book services, it is informed about one address book service: 
the consolidator. It is not informed about the two hidden 
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Services are restricted to the same stringent security 
policies imposed by the application manager module 232. 

User authentication and authorization need not be require- 
ments of the service fi-amework. 

Services are derived from published interfaces when 
available in order to de-couple the dependency on specific 
service implementation. 

Services and service stubs are resident on the client 
platform, and they are typically not downloaded. 

The ser/ice framework detects terminated communica- 
tions links, and it unregisters services that were solely 
provided over such communications links. 
The service framework is capable of dynamically discov- 
15 ering services external to the client device and using these 
services via a pre-loaded local proxy. 

The service framework is capable of selectively advertis- 
ing its services to external clients. 

The service framework provides a way to disable adver- 
tisement of its services to external clients by designating a 
service as "private" or not. 

Remote services inherit the attributes of their lookup 
service. 

The service framework provides a way to obscure or hide 
services from local clients by designating a service as 
"hidden" or not. 

The following optional functions of service framework 
235 deal with dynamically loading code onto the client in an 
alternative embodiment of the invention. 

The service framework could dynamically discover and 
download services that are external to the client device, e.g. 
on external communications nodes. 

The service framework could provide a suitable mecha- 
nism to enable or disable the function of dynamic discovery 
and downloading of services from external communications 
nodes. 
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Service Framework Characteristics 
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The service framework 235 provides the following func 
lions that satisfy the above scenarios or "use cases". 

The service framework allows a service to register itself. 

The service framework allows a service to 
itself when it becomes unavailable. 

The service framework allows appUcalions/services to 
search for a currently registered service. 

The service framework allows applications/services to 
request notification of future service registrations. 

The service framework allows applications/services to 
request notification of service attribute changes and regis- 
tration state changes. 

The service framework allows applications/services to 
cancel a notification request. 

The service framework supports service attributes that 
allow a service search to be refined. 

The service framework supports examination of service 
attributes. 

The service framework is available and locatable by all 
applications/services. 



Class/Interface Usage Overview 

The service framework 235 comprises two main compo- 
nents: a ServiceFramework class and an object implement- 
ing the ServioeRegistrar interface. The ServiceFramework 
class defines static methods used by the Service Registrar 
implementation object to make itself known and by service- 
using entities to obtain this reference. The ServiceRegistrar 
object provides service registration and lookup facilities. 

In order to use the service framework, a service or 
application obtains a reference to the ServiceRegistrar 
unregister 50 object. This is done via the static method 
ServiceFramework.getRegistrar( ). A reference to the object 
is returned to the caller. 

To register a service with the service framework, the 
service constructs a Serviceltem object and then passes 
it to the ServiceRegistrar object via the 
ServiceRcgistrar.register( ) m etho d. The Serviceltem object 
is composed of a^ervicelD^l nuil on initial registration), an 
Object implementing^' the interface to the service and an 
array of ServiceAttributeSet objects that specify the service 
atU-ibutes. The service is returned a ServiceRegisU-ation 
object which it can use to manipulate its attributes (add, 
delete and modify) and also unregister the service. Services 
are required to unregister themselves with the service frame- 
work prior to going "out of service". 

Services are discovered by constructing a ServiceTem- 
plate object and passing it to the ServiceRegistrar.lookup( ) 
method. This object specifies the service type and charac- 
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terislics that are of interest. It comprises a ServicelD, an ServiceEvent — a class indicating the occurrence of an 

array of Class objects, and an array of ServiceAttributeSet event within the service framework. It provides a reference 

objects. If a componeDt is to be wiidcarded, a null may be to the Serviceltem associated with the event. The class also 

supplied. The caller is returned an array of Serviceltem provides information to help identify the event source. This 
objects that match the supplied ServiceTemplate. 5 supports event notification by the services themselves. The 

Notification of service availability may also be class also has a reference to a "handback" object that may 

requested. A ServiceTemplate object is passed to the have been specified during registration. This can help to 

Registrar.notify( ) method along with a reference to the demultiplex events within the listener, 

caller's ServiceEventLisl^ner object A ServiceEve RemoteServiccEvent-this class is very simUar to the 

tration object is returned to the caller^Tliis object can be ServiceEvent class with the exception that it provides access 

used to cancel the notification request. When services meet- ^ _ . o • *u X 01* 

ing the criteria specified in the template become available, ^ a RemoteServiceltem rather than a Serviceltem. 

the notify( ) method in the supplied ServiccEventLtstencr ServiceEventListener— an interface to an object to be 

object is invoked and passed a ServiceEvent object. notified of the occurrence of an event within the service 

The preceding description was presented in terms of local framework. This object is registered with the service frame- 
services. From the perspective of an entity requesting a work. When an event meeting criteria specified during 
service, remote services are located and accessed in exactly registration occurs, a ServiceEvent is passed to the object via 
the same way. This is accomplished by employing a local its notify( ) method. 

proxy for the actual remote service. Remote services can be ServiceEventRegistration — a class returned when notifi- 

considered to comprise two components: a client-side or cation of service availability is requested. It contains a 

frontend portion (the proxy), and the server-side or backend reference to the event source and the identifier of the event 

portion (the remote service). Each proxy is responsible for for which notification was requested, 

discovering and linking up with its service backend. Once ServiceFramework— a class used to obtain a reference to 

this is done, the proxy registers itself with the service ^^^^^ implementing the ScrviceRegistrar interface. It 

framework. comprises the static method getServiceRegistrar( ). 

The service is made available to service-using entities and ServicelD— services are assigned an instance of this class 

has the appearance of a local service. The fact that the proxy ^^.^^ registration by the service framework. It is a unique 

needs to communicate with its service backend to carry out identifier representing a particular Serviceltem instance, 

service, functions is hidden from the service-using entity. - -.j-.l.u 

• £ * J 1 ^ ^ -iu -^^ Serviceltem — services are registered with the service 

When the service frontend loses contact v^ath the service , . • • . r .1. c • 1 

, , J • ^- 1" 1 ♦ • ♦ ^ framework using mstances or the Serviceltem class. It 

backend, e.g. the communications link termmates, it unreg- ^^^^ ^ r „ . 1 ■ . • 1 

^c ^ *L • c_ 1 contains a ServicelD, a Service object implementing the 

isters Itself from the service framework. , . , . co- a* 

,. mterf ace to the service, and an optional array ot ServiceAt- 

Remote service backends are discovered by constructing specifying the service attributes, 

a ServiceTemplate object and passing it to the j & . . , ^ . 
ServiceRegistrar.remoteLookup( ) method. This object 3, RemoteServiceltem-A remote service backend is repre- 

specifies the service type and characteristics of the remote rented by an mstance of this class. It contains the parameters 

service backend that are of interest. It comprises a null needed by the service frontend to estabUsh communications 

ServicelD, an array of Class objects, and an array of ^^h the service backend. 

ServiceAttributeSet objects. The service framework per- ServiceRegistrar— an interface to the service framework, 

forms the lookup using any available remote lookup services The object implementing this interface forms an important 

and returns either a RemoteServiceltem object or a null. component of the service framework. It contains methods to 

Notification of remote service backend availability may register a Serviceltem and to look up Serviceltems that meet 

also be requested, A ServiceTemplate object is passed to the a specified set of criteria contained in a ServiceTemplate. 

Registrar.remoteNotify( ) method along with a reference to There is also a method to request notification of events such 
the caller's ServiceEventUstener object. A ServiceEven- 45 as the registration of a service or a change m a service. This 

tRegistration object is returned to the caller. This object can method is supplied with a ServiceTemplate, a 

be used at a later time to cancel the notification request. ServiceEventListener, and an optional "handback" object to 

When services meeting the criteria specified in the tem- be passed to the listener in the ServiceEvent. 

plate become available, the notify( ) method in the supplied ServiceRegistration — an interface returned in response to 

RemoteServiceEventListener object is invoked and passed a 50 a service registration. It contains the ServicelD that was 

RemoteServiceEvent object. assigned to the service. It contains methods to modify the 

„ ^ ^ . . service's attributes as well as a method to unregister the 
Class/Interface Descnptions 

service. 

The following are class/interface descriptions appUcable ServiceTemplate^a class that specifies the match criteria 

to the service framework as implemented in one embodi- pertaining to a service lookup. It comprises a ServicelD, an 

array of class types, and an array of ServiceAttributeSets. 

Service— an interface that is implemented by service ServiceException— the class represents an exception that 

objects, occurred within the service framework, 

HiddcnSemce-ancxtensionofthcServioeinterfac^^^ ServiceUnregisteredExceptioD-a service method was 

js implemented by services to be obscured from normal j^^^^ed after the service has unregistered, 

lookups. .J 

PrivateService-an extension of the Service interface that UnknownServiceEventExcepUon-a listener received an 

is implemented by services not wishing to be advertised «vent that it didn t recognize. 

externally, ServiceName — a ServiceAttributeSet representing the 

ServiceAttributeSet — an interface used to represent arbi- 65 service name, 

trary service attributes. This is a marker interface used to ServiceStatus — a ServiceAttributeSet representing the 

group a number of typed object references. service status (i.e. availability). 
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The particular APIs, Class/Interface Descriptions, 
functions, and operations relating to the computer programs 
described herein are merely illustrative of one or more 
embodiments of the invention, and other implementations 
will be apparent to those of ordinary skill in the art. 

Methods of Operation 

FIGS. 11 and 12 together illustrate a flow diagram of a 
method 500 of providing a remote service to a communi- 
cations platform using service attributes, according to one 
embodiment of the invention. 

In 502, a wireless interface is used to couple the commu- 
nications platform (e.g. client platform 200, FIG. 5) to a 
remote communications node (e.g. server platform 300, FIG. 
6). The remote communications node includes service 
objects, at least one service attribute, and a remote lookup 
service backend (265, FIG. 9). The communications plat- 
form has a service framework (235, FIG. 5), including a 
remote lookup service frontend (261, FIG. 10). 

In 504, the remote lookup service backend communicates 
the at least one service attribute in the remote communica- 
tions node to the remote lookup service frontend. 

506 through 522 are performed asynchronously with 502 
and 504; i.e.. they can be performed at any time and not 
necessarily immediately following 504. 

In 506, a service-requesting entity (e.g. an application or 
another service) requests a remote service. Tie service- 
requesting entity constructs a service template representing 
the desired remote service. The service template has at least 
one service attribute. Hie service attribute describes a trans- 
port attribute of the remote communications node, or it 
describes a preference of the service-requesting entity 
regarding the requested remote service. The service frame- 
work includes a service registry (250, FIG. 7). 

In 508, the service-requesting entity issues the service 
template to the service framework. 

In 510, a determination is made whether the service 
framework's service registry has service objects (from this 
communications platform) matching the service template. If 
so. the method proceeds to 512 (FIG. 12); else it goes to 514. 
The service objects found in 510 could be for a remote 
service that was already discovered and registered in this 
communication platform's service registry. (The service 
lookup of the present invention can operate in at least two 
different modes: in mode (1) it satisfies the service request 
when the first match is found, whereas in mode (2) it looks 
for all matching requests. In the present example, it is 
assumed that the service lookup function is operating in 
mode (2).) 

In 512 (FIG. 12), the service framework buffers such 
matching service objects for the service-requesting entity. 

In 514, a determination is made by a suitable program 
module, such as a transition mask, described elsewhere 
herein, whether the at least one service attribute in the 
remote communications node matches the at least one 
service attribute in the service template. If so, the method 
proceeds to 516; else it goes to 522. 

In 516. the service framework performs a lookup on the 
remote communications node for any service objects match- 
ing the service template (including the at least one service 
attribute) that was constructed by the service-requesting 
entity. 

In 518, if any matching service objects are found on the 
remote node, the method proceeds to 520; else it goes to 522. 

In 520, the service framework buffers the matching ser- 
vice objects for the service-requesting entity. 



10,916 Bl 

30 

In 522, the buffered service objects (from this communi- 
cations platform and/or a remote communications node) are 
returned to the service-requesting entity, or a null is returned 
if none were found. 

5 In summary, the service framework provides only the 
remote service(s) to the service- requesting entity that was 
specified by the service template including its at least one 
service attribute. This minimizes communications traflSc on 
the wireless communications link, and it conserves memory 

10 and processing resources on the communications platform. 
The various elements illustrated in FIGS. 1-7 are merely 
representational and are not drawn to scale. Certain propor- 
tions thereof may be exaggerated, while others may be 
minimized. The drawings are intended to illustrate various 
implementations of the invention that can be understood and 
appropriately carried out by those of ordinary skill in the art. 
Any arrangement, which is calculated to achieve the same 
purpose, may be substituted for the specific embodiments 
shown. 

20 

The sequences and methods shown and described herein 
can be carried out in a different order than those described. 
It will also be understood that while certain flowcharts in 
FIGS. 8-12 have an "End" block, in general the methods 
2 J that they depict are continuously performed. The particular 
sequences, functions, and operations depicted in FIGS. 8-12 
are merely illustrative of one or more embodiments of the 
invention, and other implementations will be apparent to 
those of ordinary skiU in the art. 

Conclusion 

What have been described are methods and apparatus for 
providing a service framework within a wireless information 
appliance system that provides a standard, consistent, sim- 
35 plified way for services to make themselves available and 
for service-using entities to locate and connect with the 
services of interest to them. 

The meth ods and apparatu s^ of the present in ven^on 
supp'Sf t 'Ihg ' jdejiufa cjtuoj'Ji^ ' i>!l?ivKxs'To 

40 WfiKfff**uscr'T5 

Wdfiy^^^^ing^.power,,jm^^ 
r£^^c^^ai|ayeat£ytje^user^equipment. 

The present invention provides an innovative way to 
implement dynamic networking for managing distributed 
and transient services. It does so in a manner that offers a 
high degree of security. It completely eliminates the 
dynamic downloading of the service code and its execution 
in the client. The asymmetric lookup/advertising/discovery 
of services increases client privacy. 

The implementing platform is extremely light-weight due 
to eliminating the downloading of service code, eliminating 
object serialization and remote method invocation (RMI), 
performing asymmetric lookup/advertising/discovery of 
services, performing just-in- time lookups of required 
services, and consolidating lookup activities by the local 
lookup services. 

Support is provided for life-cycle management of the part 
of the disU-ibuted service on the client, including hot- 
upgrades, in the service interface. 

Communication is minimized between the wireless client 
and server for adminisU"ative functions by eliminating down- 
loading of service code, eliminating object serialization and 
RMI, performing just -in-time lookups, and batching lookup 
65 requests. 

The consolidation of similar services is performed 
through the use of the "hidden" service feature. 
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The inheritance of attributes supports a hierarchical ser- 
vice tree that is useful for constraining lookup. 

The implementation of the invention is language- 
independent, both on the client and on the server. 

The present invention is conserving of application and ^ 
platform resources, particularly in mobile platforms. In the 
present invention, only those services are looked up and 
connected that fulfill user-specified parameters and/or that 
stand a reasonable chance of being found and connected to, 
especially in view of changing conditions to which mobile 
platforms may be subjected. 

The methods and apparatus described herein are quite 
versatile and can be implemented in any type of information 
appliance system. As described herein, the advantages of the 
present invention will be apparent to those of skill in the art 
and will provide improved methods and apparatus for 
locating, connecting with, and utilizing wireless services. 

While the invention has been described in terms of 
specific examples, it is evident that many alternatives and 
variations will be apparent to those skilled in the art based 
on the description herein, and it is intended to include such 
variations and alternatives in the claims. 

What is claimed is: 

1. In a communications platform comprising a service- 
requesting entity, a service framework and an interface with 
which a remote communications node can be coupled to the 
communications platform, the remote communications node 
comprising a remote service, the method comprising; 

the service-requesting entity requesting the remote ser- 30 
vice; 

using the interface to provide only the remote service 
requested by the service-requesting entity; 

the service-requesting entity constructing a service tem- 
plate representing the remote service, the service tem- 35 
plate comprising at least one service attribute; 

the service -requesting entity issuing the service template 
to the service framework; and 

if the service framework has service objects matching the 
service template, the service framework returning to 
the service-requesting entity such service objects, oth- 
erwise returning a null. 

2. In a communications platform comprising a service- 
requesting entity, a service framework comprising a remote 
lookup service frontend, and an interface with which a 
remote communications node can be coupled to the com- 
munications platform, the remote communications node 
comprising a remote service and a remote lookup service 
backend, the method comprising; 

the service-requesting entity requesting the remote ser- 
vice; 

using the interface to provide only the remote service 
requested by the service-requesting entity; 

the service- requesting entity constructing a service tem- 55 
plate representing the remote service, the service tem- 
plate comprising at least one service attribute; 

the service-requesting entity issuing the service template 
to the service framework; and 

the remote lookup service frontend communicating with 60 
the remote lookup service backend. 

3. The method recited in claim 2, wherein the remote 
communications node comprises at least one service 
attribute, the method further comprising: 

the remote lookup service backend communicating the at 65 
least one service attribute in the remote communica- 
tions node to the remote lookup service frontend. 
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4. The method recited in claim 3, the method further 
comprising: 

the service framework determining whether the at least 
one service attribute in the remote communications 
node matches the at least one service attribute in the 
service template. 

5. The method recited in claim 3, the method further 
comprising: 

if and only if the at least one service attribute in the remote 
communications node matches the at least one service 
attribute in the service template, providing the remote 
service to the service-requesting entity. 

6. A communications platform comprising: 
a processor; 

a wireless interface coupled to the processor to enable the 
communications platform to communicate with a 
remote node, wherein the remote node comprises at 
least one service attribute and a remote lookup service 
backend; and 

a memory coupled to the processor and comprising: 
a service-requesting entity to request a service on the 
remote node; 

at least one service attribute specified by the service - 
requesting entity and associated with the service; 

a service framework to discover the service and to 
provide the service to the service -requesting entity as 
specified by the at least one service attribute; 

a remote lookup service frontend to receive information 
from the remote lookup service backend over the 
wireless interface concerning the at least one service 
attribute on the remote node; and 

a first program module to determine whether the at least 
one service attribute on the remote node matches the 
at least one service attribute in the service template 
and, if so, to provide the service to the service - 
requesting entity. 

7. A communications system comprising: 

at least one remote node, wherein the at least one remote 
node comprises at least one service attribute and a 
remote lookup service backend; and 

at least one communications platform comprising: 
a processor; 

a wireless interface coupled to the processor to enable 
the at least one communications platform to com- 
municate with the at least one remote node; 
a memory coupled to the processor and comprising: 
a service-requesting entity to request a service on the 

at least one remote node; 
at least one service attribute specified by the service - 
requesting entity and associated with the service; 
a service framework to discover the service and to 
provide the service to the service-requesting entity 
as specified by the at least one service attribute; 
a remote lookup service frontend to receive infor- 
mation from the remote lookup service backend 
over the wireless interface concerning the at least 
one service attribute on the at last one remote 
node; and 

a first program module to determine whether the at 
least one service attribute on the at last one remote 
node matches the at least one service attribute in 
the service template and, if so, to provide the 
service to the service-requesting entity. 

8. A method of providing a service to a communications 
platform, wherein the communications platfonn comprises a 
service-requesting entity and a service framework, wherein 
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the communications platform further comprises an interface 
to which a remote communications node can be coupled, and 
wherein the service resides on the remote communications 
node, the method comprising: 

the service-requesting entity constructing a service tem- 
plate representing a desired service, the service tem- 
plate comprising at least one service attribute; 
the service-requesting entity issuing the service template 

to the service framework; and 
if the service framework has service objects matching the 
service template, the service framework returning to 
the service -requesting entity an array of such service 
objects, otherwise returning a null. 
9. The method recited in claim 8, wherein the remote 
communications node further comprises a remote lookup 
service badcend, and wherein the service framework further 
comprises a remote lookup service f route nd, the method 
further comprising: 

the remote lookup service frontend communicating with 
the remote lookup service backend. 
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10. The method recited in claim 9, wherein the remote 
communications node further comprises at least one service 
attribute, the method further comprising: 

the remote lookup service backend communicating the at 
least one service attribute in the remote communica- 
tions node to the remote lookup service frontend. 

11. The method recited in claim 10, the method further 
comprising: 

the service framework determining whether the at least 
one service attribute in the remote communications 
node matches the at least one service attribute in the 
service template. 

12. The method recited in claim 11, the method further 
comprising: 

if and only if the at least one sendee attribute in the remote 
communications node matches the at least one service 
attribute in the service template, providing the remote 
service to the service-requesting entity. 
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